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Abstract 


In order to deploy DNSSEC (Domain Name System Security Extensions) 
operationally, DNSSEC aware servers should only perform automatic 
inclusion of DNSSEC RRs when there is an explicit indication that the 
resolver can understand those RRs. This document proposes the use of 
a bit in the EDNSO header to provide that explicit indication and 
describes the necessary protocol changes to implement that 
notification. 


1. Introduction 


DNSSEC [RFC2535] has been specified to provide data integrity and 
authentication to security aware resolvers and applications through 
the use of cryptographic digital signatures. However, as DNSSEC is 
deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware 
servers. In such situations, the DNSSEC-aware server (responding to 
a request for data in a signed zone) will respond with SIG, KEY, 
and/or NXT records. For reasons described in the subsequent section, 
such responses can have significant negative operational impacts for 
the DNS infrastructure. 


This document discusses a method to avoid these negative impacts, 
namely DNSSEC-aware servers should only respond with SIG, KEY, and/or 
NXT RRs when there is an explicit indication from the resolver that 
it can understand those RRs. 


For the purposes of this document, "DNSSEC security RRs" are 
considered RRs of type SIG, KEY, or NXT. 
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The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Rationale 


Initially, as DNSSEC is deployed, the vast majority of queries will 
be from resolvers that are not DNSSEC aware and thus do not 
understand or support the DNSSEC security RRs. When a query from 
such a resolver is received for a DNSSEC signed zone, the DNSSEC 
specification indicates the nameserver must respond with the 
appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to 
512 bytes [RFC1035], responses including DNSSEC security RRs have a 
high probability of resulting in a truncated response being returned 
and the resolver retrying the query using TCP. 


TCP DNS queries result in significant overhead due to connection 
setup and teardown. Operationally, the impact of these TCP queries 
will likely be quite detrimental in terms of increased network 
traffic (typically five packets for a single query/response instead 
of two), increased latency resulting from the additional round trip 
times, increased incidences of queries failing due to timeouts, and 
significantly increased load on nameservers. 


In addition, in preliminary and experimental deployment of DNSSEC, 
there have been reports of non-DNSSEC aware resolvers being unable to 
handle responses which contain DNSSEC security RRs, resulting in the 
resolver failing (in the worst case) or entire responses being 
ignored (in the better case). 


Given these operational implications, explicitly notifying the 
nameserver that the client is prepared to receive (if not understand) 
DNSSEC security RRs would be prudent. 


Client-side support of DNSSEC is assumed to be binary -- either the 
client is willing to receive all DNSSEC security RRs or it is not 
willing to accept any. As such, a single bit is sufficient to 
indicate client-side DNSSEC support. As effective use of DNSSEC 
implies the need of EDNSO [RFC2671], bits in the "classic" (non-EDNS 
enhanced DNS header) are scarce, and there may be situations in which 
non-compliant caching or forwarding servers inappropriately copy data 
from classic headers as queries are passed on to authoritative 
servers, the use of a bit from the EDNSO header is proposed. 


An alternative approach would be to use the existence of an EDNSO 

header as an implicit indication of client-side support of DNSSEC. 
This approach was not chosen as there may be applications in which 
EDNSO is supported but in which the use of DNSSEC is inappropriate. 
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3. Protocol Changes 


The mechanism chosen for the explicit notification of the ability of 
the client to accept (if not understand) DNSSEC security RRs is using 
the most significant bit of the Z field on the EDNSO OPT header in 
the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In 
the context of the EDNSO OPT meta-RR, the DO bit is the first bit of 
the third and fourth bytes of the "extended RCODE and flags" portion 
of the EDNSO OPT meta-RR, structured as follows: 


+0 (MSB) +1 (LSB) 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

oO: | EXTENDED-RCODE VERSION | 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 

2: |DO] Z | 


+--+--+--+--+--+--+--+--+--+--+--+--+--+--++ 


Setting the DO bit to one in a query indicates to the server that the 
resolver is able to accept DNSSEC security RRs. The DO bit cleared 
(set to zero) indicates the resolver is unprepared to handle DNSSEC 
security RRs and those RRs MUST NOT be returned in the response 
(unless DNSSEC security RRs are explicitly queried for). The DO bit 
of the query MUST be copied in the response. 


More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY, 
or NXT RRs to authenticate a response as specified in [RFC2535] 
unless the DO bit was set on the request. Security records that 
match an explicit SIG, KEY, NXT, or ANY query, or are part of the 
zone data for an AXFR or IXFR query, are included whether or not the 
DO bit was set. 


A recursive DNSSEC-aware server MUST set the DO bit on recursive 
requests, regardless of the status of the DO bit on the initiating 
resolver request. If the initiating resolver request does not have 
the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC 
security RRs before returning the data to the client, however cached 
data MUST NOT be modified. 


In the event a server returns a NOTIMP, FORMERR or SERVFAIL response 
to a query that has the DO bit set, the resolver SHOULD NOT expect 
DNSSEC security RRs and SHOULD retry the query without EDNSO in 
accordance with section 5.3 of [RFC2671]. 
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Security Considerations 


The absence of DNSSEC data in response to a query with the DO bit set 
MUST NOT be taken to mean no security information is available for 
that zone as the response may be forged or a non-forged response of 
an altered (DO bit cleared) query. 


IANA Considerations 


EDNSO [RFC2671] defines 16 bits as extended flags in the OPT record, 
these bits are encoded into the TTL field of the OPT record (RFC2671 
section 4.6). 


This document reserves one of these bits as the OK bit. It is 
requested that the left most bit be allocated. Thus the USE of the 
OPT record TTL field would look like 


+0 (MSB) +1 (LSB) 
+—-+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
0: | EXTENDED-RCODE VERSION | 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
2: |do| Z | 


+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
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Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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